주요 통신 프로토콜 비교: HTTP, WebSocket, MQTT

현대적인 애플리케이션은 단순히 웹 페이지를 보여주는 것을 넘어 실시간 채팅, 주식 시세 업데이트, 스마트홈 기기 제어 등 다양한 통신 방식을 요구합니다. 각 상황에 최적화된 3대 프로토콜을 비교해 보겠습니다.

---

1. HTTP (HyperText Transfer Protocol)

가장 대중적인 비연결성(Connectionless) 기반의 요청-응답(Request-Response) 프로토콜입니다.

• 방식: 클라이언트가 요청을 보내면 서버가 응답하고 연결을 끊습니다.
• 장점: 설계가 단순하고 표준화되어 있어 어디서든 사용 가능하며, REST API의 기반이 됩니다.
• 단점: 실시간 통신을 위해 '폴링(Polling)' 방식을 써야 하므로 서버 부하가 크고 헤더 오버헤드가 발생합니다.
• 주요 용도: 일반적인 웹 서핑, 문서/이미지 전송, 일반적인 데이터 API.

---

2. WebSocket (웹소켓)

HTML5 표준의 일부로 도입된 전이중(Full-Duplex) 양방향 통신 프로토콜입니다.

• 방식: 처음에 HTTP로 연결(Handshake)을 맺은 뒤, 전용 프로토콜로 업그레이드하여 연결을 계속 유지합니다.
• 장점: 한 번 연결되면 헤더가 매우 작아 통신 효율이 높고, 서버가 클라이언트에게 언제든 먼저 데이터를 보낼 수 있습니다.
• 단점: 연결을 계속 유지해야 하므로 동시 접속자가 많을 때 서버 메모리 부담이 큽니다.
• 주요 용도: 실시간 채팅, 주식 시세 대시보드, 멀티플레이어 게임.

---

3. MQTT (Message Queuing Telemetry Transport)

지연 시간이 길거나 네트워크가 불안정한 환경에서 동작하도록 설계된 발행-구독(Pub/Sub) 기반의 경량 프로토콜입니다.

• 방식: 중간에 브로커(Broker)를 두고, 클라이언트는 특정 주제(Topic)를 구독하거나 메시지를 발행합니다.
• 장점: 헤더가 매우 작고(최소 2바이트), 저전력/저대역폭 환경에 최적화되어 있습니다. QoS(전송 품질 보장) 옵션을 제공합니다.
• 단점: 중앙 브로커 관리가 필요하며, 일반적인 웹 브라우저에서는 직접 지원하지 않아 라이브러리가 필요합니다.
• 주요 용도: IoT 기기 제어(스마트홈), 센서 데이터 수집, 모바일 알림(Push).

---

4. 핵심 비교 요약표

비교 항목	HTTP	WebSocket	MQTT
통신 모델	Request-Response	Full-Duplex	Publish-Subscribe
연결 상태	비연결성 (Stateless)	연결 지향 (Stateful)	연결 지향 (Stateful)
방향성	단방향 (클라 -> 서버)	양방향 (동시 전송)	양방향 (브로커 경유)
오버헤드	높음 (큰 헤더)	낮음 (작은 헤더)	매우 낮음 (최소 헤더)
OSI 계층	애플리케이션 계층 (L7)	애플리케이션 계층 (L7)	애플리케이션 계층 (L7)

---

5. 무엇을 선택해야 할까?

1. "표준적인 데이터 요청과 응답이 필요하다" -> HTTP를 사용하세요.
2. "웹 브라우저에서 딜레이 없는 실시간 채팅이나 게임을 만든다" -> WebSocket이 정답입니다.
3. "전력 소모가 적어야 하는 임베디드 기기나 수만 개의 센서를 제어한다" -> MQTT를 강력 추천합니다.

결론

현대적인 서비스는 이들을 혼합하여 사용합니다. 사용자는 HTTP로 로그인하고, 채팅은 WebSocket으로 주고받으며, 알림 서버는 MQTT로 모바일 기기에 푸시를 보내는 식입니다. 각 도구의 특성을 이해하고 적재적소에 배치하는 설계 능력을 길러보세요!